Secure elements are small devices comprising a memory, a microprocessor and an operating system for computing treatments. Such secure elements may comprise a plurality of memories of different types, like non-volatile memory and volatile memory. They are called “secure” because they are able to control the access to the data they contain and to authorize or not the use of data by other machines. The secure elements may also provide computation services based on cryptographic components. In general, secure elements have limited computing resources and limited memory resources and they are intended to be connected to a host machine which provides them with electric power. Secure elements may be removable or fixed to a host machine. For example, smart cards are a kind of secure elements.
A secure element may contain applications and their associated applicative data which encompass user data, file systems and secret key. Such an application may be developed as a package or a set of packages which is stored into the secure element. One or several instances of the application are then created as needed. Each instance owns, handles and store its own instance data.
Secure elements may be accessed by a remote server via a wireless channel or through a wired network, like Internet for instance. For example, secure elements which are intended to be used in Telecom domain or Machine-To-Machine (M2M) domain are able to manage an OTA (Over-The-Air) channel. These secure elements may also be accessed through the HyperText Transfer Protocol, usually called HTTP or HTTPS for the secure mode. Thus, a distant server can remotely manage the content of a secure element like an UICC (Universal Integrated Circuit Card) through a dedicated communication session using a specific protocol. For example, the server may use the RAM (Remote Applet Management) mechanism as defined by GlobalPlatform v 2.2 standard—Amendment B “RAM over HTTP” or the OMA-DM (Open Mobile Alliance—Device Management) protocol as defined by OMA-TS-DM V1.2.1 standard.
According to JavaCard™ specifications, a package may be loaded in a secure element through a Converted Applet file (herein referred to as “CAP file”). The package installation comprises a step of linking the package to the operating system. This linking step allows to map symbolic addresses used in the CAP file into physical addresses depending on the current operating system. This linking step is carried out only once in the secure element then several components (Header, Directory, Import, Constant Pool and Reference Location components) of the CAP file are deleted. This allows fast execution at runtime and memory saving.
A remote server can send a new version or an upgrade of the operating system of the secure element. In this case, the packages linked to the previous operating system are deleted then reloaded in the secure element. This new loading of packages triggers the re-installation of these packages which in turn triggers the linking of these packages to the new operating system.
The re-loading of a package may require a large part of the bandwidth on the network. This problem is exacerbated when a large number of secure elements must be upgraded. Moreover, the remote server may have no access to the relevant package if this package has been installed by another entity like a third party.
There is a need for allowing to maintain a package in a functional state when the operating system of a secure element is updated.